Just a quick note: it appears that you already had a mapping to run a visually selected bit of code. My patch differs in that it works not just with linewise selections but also with character and block selections.

Dan, thanks for your contributions. It'd be easier to deal with these three things as separate pull requests.

1. is a no brainer that I'm fine with merging. (although what about doctest-style python code in ReST examples?)
2. Could you implement the motion commands in Python? I suspect that most users of vim-ipython are python programmers, and not necessarily keen on dealing with VimScript (i'm in that camp, myself). It'd be nice for the motion commands to work with Alt-S when not in visual mode. That was we stick with just ctrl-s and alt-s in various modes
3. Is there a clear advantage to doing this? It seems like this kind of convention forces you to create a new vim command for every new python function which simply calls the python function. Given my comment about vim-ipython users being python programmers was the reason I kept the mappings as :py somfunc()

looking forward to your feedback (sorry, i hate it myself when my contributions get pushed back a bit from upstream)

Paul,

I could redo this as two separate pull requests if you would like. I am new to using git in a collaborative way. Regarding your comments:

1. Setting the syntax type to "rest" was what I came up with after a small bit of research on google. It seems to work reasonably well for me, after installing the rest syntax file. Doctest code is not colorized with python style though. Taking another look, it seems that maybe it should be "set syntax=rst". This isn't as colorful, but the associated rst.vim file is included as part of vim. So it seems that "rst" is the official syntax code for ReST documentation. Improving the coloring for it is then someone else's job...

2. I think that it is possible to implement in python, but it would be a lot more difficult. It seems that when text is highlighted character-wise instead of line-wise, there are some hoops to jump through. You first need to obtain the lines from vim.current.range, and then you need to look at other variables to determine which column of the first line to start at and which column of the last line to stop at. Additionally, it would perhaps be necessary to do some extra checks to determine which selection mode (char, block, line) was in use. I should point out that I am not an expert on vimscript either, and in fact I set out to learn how to do this with vimscript only after seeing how hard it would be with python. In any case, even if the guts were written in python, I think it would need to be wrapped in a vim function anyway in order to use "set operatorfunc".

   It would be possible to make it work using Alt-S though. Just change <leader>p to <M-S> and change <leader>pp to <M-S><M-S>. I see that currently <M-S> is mapped to a dedent version of run_{this,these}_lines. It was my intention to make a further pull request to implement the dedent using python and submit that as the next pull request (the current dedent method doesn't work for me). Then dedent could be made part of the operator map that is the subject of this pull request.

3. The advantage to the <Plug> mappings is that sometimes they are more complicated than just a function call. For instance, even just running the current line in insert mode is <C-\><C-O>:python run_this_line()<CR>. This is harder to write, and less transparent than just using <Plug>IPyRunLine. The latter will do the right thing whether used in either normal or insert mode. Other ones like :py get_doc_buffer() probably don't need the <Plug> mappings though.

I have other suggestions that would perhaps best be discussed as part of a separate pull request. For instance, the key mapping should be made buffer-local with the <buffer> option, since it only makes sense to have them within the python buffer.